Method and apparatus to validate a subscriber line

ABSTRACT

A method of providing validation data associated with a subscriber line of a telecommunication network. The method includes obtaining line data of the subscriber line wherein the line data is suitable for interrogating a line identification database (LIDB). The method interrogates the LIDB with the line data to obtain reference subscriber data associated with the line data, and processes the reference subscriber data to obtain validation data associated with the subscriber line. The invention extends to a subscriber line validation system to validate a subscriber line of a communication network.

The present application is a continuation of U.S. patent applicationSer. No. 13/860,085, filed Apr. 10, 2013, which is a continuation ofU.S. patent application Ser. No. 13/078,371, filed on Apr. 1, 2011,which is a continuation of U.S. patent application Ser. No. 12/916,891,filed on Nov. 1, 2010, which issued as U.S. Pat. No. 8,379,815, which isa continuation of U.S. patent application Ser. No. 11/836,603, filed onAug. 9, 2007, which issued as U.S. Pat. No. 7,848,500, which is acontinuation of U.S. patent application Ser. No. 11/400,737, filed Apr.6, 2006, which issued as U.S. Pat. No. 7,848,504, which is acontinuation of U.S. patent application Ser. No. 10/225,098, filed Aug.20, 2002, which issued as U.S. Pat. No. 7,054,430, which claims thebenefit of the filing date of U.S. Provisional Patent Application No.60/314,604, filed Aug. 23, 2001.

BACKGROUND TO THE INVENTION

An increasing number of vendors are offering goods and/or services whichmay be purchased via a communication network such as a telecommunicationnetwork. For example, the customer may conduct a transaction via asubscriber line using a landline telephone or a personal computer.Conventionally, credit or debit card details are furnished by thecustomer to the vendor to effect payment for the goods and/or services.As many customers are hesitant to supply credit or debit card detailsover a communication network, an alternate method of payment would beadvantageous. However, if an alternate method is used, verification ofthe payment method should preferably take place prior to concluding thetransaction.

SUMMARY OF THE INVENTION

In accordance with the invention, there is provided a method to providevalidation data associated with a subscriber line of a telecommunicationnetwork, the method including:

obtaining line data of the subscriber line, the line data being suitablefor interrogating a line identification database (LIDB);

interrogating the LIDB with the line data to obtain reference subscriberdata associated with the line data; and

processing the reference subscriber data to obtain validation dataassociated with the subscriber line.

The LIDB may be a conventional LIDB used by a service provider, e.g. alocal exchange carrier, to investigate a destination or termination lineto which a carrier requests a connection.

The method may include analyzing the reference subscriber data todetermine if the data is associated with a billing telephone number(BTN) and, if so, generating an approval or a decline status. In oneexemplary embodiment, the line data is automatic number identification(ANI) data and, the method includes interrogating the LIDB using the ANIdata (herein also referred to as the ANI). The validation data may beprocessed to determine whether the subscriber line is a billable linehaving an associated account to which goods or services can be billed.

The reference subscriber data received from the LIDB may be processedselectively to approve a transaction requested via the subscriber line.In one exemplary embodiment, the reference subscriber data is in theform of conventional LIDB codes and the operation to process the datamay include generating a modified code from at least one LIDB code. Incertain embodiments, a common modified code is generated from aplurality of LIDB codes. The modified codes may be arranged in abillable group and a non-billable group.

The method may include conducting fraud control checks on the accountassociated with the subscriber line number or ANI. The fraud controlchecks may include at least one of the operations selected from thegroup consisting of checking if adjustments have been made to theaccount associated with the ANI, verifying a user entered ZIP code withZIP data from a ZIP data source, verifying user entered address datawith address data from an address data source, checking if the area codeassociated with the ANI has changed, checking if the ANI and the BTNmatch, and checking if the BTN or ANI are missing from the record.

The method may include interrogating a network database with the ANI todetermine if the subscriber line is a billable subscriber line and, ifnot, generating a decline status. The method may include interrogatingwith the line data at least one of a competitive local exchange carrier(CLEC) database, a 42 BLOCK database, a Block and Cancel database, anunpaid bills database, an off network database, an on network database,an address verification database, a regional account office (RAO)database, an operating company number (OCN) database, and a customeraccount record exchange (CARE) database and selectively generating oneof a decline status and an approved status in response to theinterrogation.

The method may include receiving the line data from a vendor of goods orservices (e.g. an Internet Service Provider (ISP)); and communicating atleast the decline status to the vendor.

In one exemplary embodiment, the charges raised by the vendor areincluded in an account submitted by the exchange carrier to a subscriberfor use of the subscriber line.

Further in accordance with the invention, there is provided acomputer-readable medium for storing a set of instructions that, whenexecuted by a machine, cause the machine to execute the method.

Still further in accordance with the invention, there is provided asubscriber line validation system for validating a subscriber line of acommunication network, the system including:

a communication module for receiving line data of the subscriber line,the line data being suitable for interrogating a line identificationdatabase (LIDB);

an interrogation module for interrogating the LIDB with the line data toobtain reference subscriber data associated with the line data; and

a processor module for processing the reference subscriber data toobtain validation data associated with the subscriber line.

In one exemplary embodiment, the LIDB is a conventional LIDB. However,in other embodiments, a plurality of LIDBs may be provided that are usedby one or more service providers, e.g. local exchange carriers, toinvestigate a destination or termination line to which a subscriber linerequests a connection.

In one exemplary embodiment, the processor module is configured toanalyze the reference subscriber data to determine if the data isassociated with a billing telephone number (BTN) and, if so, the systemgenerates a decline status. In one embodiment, the line data isautomatic number identification (ANI) data and the processor moduleinterrogates the LIDB using the ANI data.

The validation data may be processed to determine if the subscriber lineis a billable line having an associated account to which goods orservices can be billed.

The reference subscriber data may be received from the LIDS and may beprocessed selectively to approve a transaction requested via thesubscriber line.

The reference subscriber data is preferably in the form of conventionalLIDB codes and the processor module may generate a modified code from atleast one LIDB code. In certain embodiments, the processor modulegenerates a common modified code from a plurality of different LIDScodes. In one embodiment, the modified codes arc arranged in a billablegroup and a non-billable group.

In certain embodiments, the system may conduct fraud control checks onan account associated with the ANI. The processor module may beconfigured to conduct at least one fraud control check selected from thegroup consisting of checking if adjustments have been made to theaccount associated with the ANI, verifying a user entered ZIP code witha ZIP data source, verifying user entered address data with an addressdata source, checking if the area code associated with the ANI haschanged, checking if the ANI and the BTN match, and checking if the BTNor ANI are missing from the record.

The processor module may interrogate a network database with the ANI todetermine if the subscriber line is a billable subscriber line and, ifso, generate a decline status.

In certain embodiments, the system may interrogate at least one of acompetitive local exchange carrier (CLEC) database, a 42 BLOCK database,a Block and Cancel database, an unpaid bills database, an off networkdatabase, an on network database, an address verification database, aregional account office (RAO) database, an operating company number(OCN) database, and a customer account record exchange (CARE) database.

The system may include receiving the line data from a vendor of goods orservices; and communicating at least the decline status to the vendor.Charges raised by the vendor may be included in an account submitted bythe exchange carrier to a subscriber for use of the subscriber line.

Further in accordance with the invention, there is provided a system toprovide validation data associated with a subscriber line of atelecommunication network, the system including means for obtaining linedata of the subscriber line, the line data being suitable forinterrogating a line identification database (LIDB); means forinterrogating the LIDB with the line data to obtain reference subscriberdata associated with the line data; and means for processing thereference subscriber data to obtain validation data associated with thesubscriber line.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is now described, by way of example, with reference to theaccompanying diagrammatic drawings.

In the drawings,

FIG. 1 shows a schematic block diagram of a subscriber line validationsystem, in accordance with the invention, for validating a subscriberline of a communication network;

FIGS. 2 to 4 show a schematic flow chart of a method, in accordance withthe invention, for validating the subscriber line;

FIG. 5 shows a schematic block diagram of how the system may be used ina conventional commercial environment; and

FIG. 6 shows a schematic representation of a sample telephone billplatform which the system can automatically update.

FIG. 7 shows a diagrammatic representation of machine in the exemplaryform of a computer system within which a set of instructions, forcausing the machine to perform any one of the methodologies discussedherein, may be executed.

DETAILED DESCRIPTION

Referring to the drawings, reference number 10 generally indicates anexemplary subscriber line validation system, in accordance with anaspect of the invention, for validating a subscriber line 17 of asubscriber. In one exemplary embodiment, the subscriber line 17 is atelephone line or the like which a consumer or business 11 (see FIGS. 1and 5) obtains from a telephone company (Telco) 13 or a local exchangecarrier (LEC). As described in more detail below, the system 10 usesline data in the exemplary form of an automatic number identification(ANI) service to obtain the telephone line number of the subscriber line17 thereby to validate the subscriber line 17 when the subscriber line17 initiates a communication or connection. In one exemplary embodiment,the line number obtained from the ANI service is used to investigatevarious databases to obtain, for example, an indication of the creditworthiness of the subscriber account associated with the subscriber line17. It is to be appreciated that any electronic apparatus, e.g. apersonal computer, PDA, cellular telephone, or the like may be used toinitiate the communication.

Referring in particular to FIG. 1 of the drawings, the system 10includes an application program interface (API) 14 which is connected toa vendor 12 or service provider (see also FIG. 5) of goods and/orservices which requires validation of a subscriber account. The vendor12, which could for example be an Internet Service Provider, may requestthe validation of the subscriber line 17 prior to concluding anelectronic transaction with a subscriber (e.g., a consumer or business11) via the subscriber line 17. It is, however, to be appreciated thatthe API 14 may be connected to a variety of different hosts or clientswhich require validation of a subscriber line via which the vendor maycarry out transactions for goods and/or services.

In one exemplary embodiment, the system 10 is connected to a pluralityof vendors which conduct transactions with users via line terminationequipment such as a telephone, a personal computer or the like. Suchvendors, when conducting transactions, may preferably charge a user fortheir services by adding such charges to a telephone account of the userrather than charging the goods and/or services to a credit card, debitcard, or the like. Accordingly, the validation of the subscriber line17, and the subscriber account associated with the subscriber line 17,may be of benefit to the vendor 12 prior to completing a transaction.The validation may include determining whether or not the subscriberline 17, via which the communication is made to the vendor, is abillable line and, accordingly, the subscriber account associated withthe subscriber line 17 may thus be billed for the transaction.

In one exemplary embodiment, the vendor 12 communicates a request to thesystem 10 and forwards the subscriber line number, determined by the ANIservice, to the system 10 via its API 14. The system 10 then processesthe information received from the vendor 12 and provides a validationstatus, e.g. a code indicating a valid billable number or a codeindicating that the subscriber line number is not a valid billablenumber (e.g. unbillable or non-billable). In particular, a plurality ofcodes associated with various statuses of the subscriber line 17 may becommunicated to the vendor 12 as described in more detail below.

The system 10 includes hardware and software to implement the invention.In the exemplary embodiment, the system 10 includes a comparator module18, a threshold database 20, an OFFNET database 22, an ONNET database24, a competitive local exchange carrier (CLEC) database 26, a 42 BLOCKdatabase 28, a block and cancel database 30, an unbilled and/or unpaidbills database 32, line identification database (LIDB) short term cache34, a validity check module 36, a regional account office (RAO) database38, an operating company number (OCN) database 40, an ONNET database 42,an address verification database 44, a customer account record exchange(CARE) results database 46, an ANI watch database 48, and an NPA(Numbering Plan Area) exchange database 50. It is to be appreciatedthat, in less sophisticated embodiments of the invention, all of theabove databases need not be included. However, for enhanced accuracy,all of the above databases are preferably included. Further databasesmay also be included to further enhance the reliability of thevalidation process.

In addition to any one or more of the above databases, the system 10 isin communication via a conventional communication channel with anoff-site or, in some embodiments, on-site line identification database(LIDB) host 52. The LIDB host 52 may include a line number portability(LNP) database. In one exemplary embodiment, the LNP database may frontend access to a plurality of industry standard LIDBs (e.g. 13 differentLIDBs). The LNP database may however be a separate database. Asdescribed in more detail below, the system 10 communicates thesubscriber line number to the LIDB host 52 which, in turn, communicatesreference subscriber data in the form of industry standard LIDB codesback to the system 10 for processing. The system 10 then processes theLIDB codes to provide the vendor with validation data relating to thesubscriber line 17. Unlike conventional LIDB applications which use LIDBto make decisions regarding destination subscriber lines or callcompletion decisions, e.g. decisions for calling cards, collect andthird party toll services or the like, the system 10 may be used toidentify telephone numbers being served by CLECs in order to ensure thatcalls are routed correctly on ported lines.

Broadly, the system 10 has a variety of different components, includinga communication module defined by the API 14, and a processor module 54.The a processor module 54 includes the various databases 20 to 32 aswell as the comparator module 18 and the validity check module 36, andan interrogation module 56 for interrogating the LIDS host 52. It is tobe appreciated that the aforementioned modules may be defined by one ormore servers with associated databases. Further, in the drawings, theLIDB host 52 is shown as a single database but may comprise manydifferent LIDB databases maintained by various LECs and, accordingly,may be located at various different geographic locations.

Referring in particular to FIGS. 2 to 4 of the drawings, a flow chartdescribing the method of operation of the system 10 is shown. In oneexemplary embodiment, a vendor 12 initiates a request to the system 10to validate a subscriber line 17 via which the vendor 12 wishes totransact with a customer (consumer or business 11). As shown atoperation 60, the system 10 first checks to see if the subscriber linenumber is present in the request from the vendor 12 and, if no linenumber is present, a return code 121 is generated and communicated tothe vendor as shown at operation 62. The code 121 indicates to thevendor that the system 10 is unable to process the request. If, however,the subscriber line number is present in the request from the vendor 12,the system 10 then checks if the subscriber line number captured(hereinafter also referred to as the ANI) and a billing telephone number(BTN) match, as shown at operation 64 (see also the comparator module 18in FIG. 1). In one exemplary embodiment, the BTN may be sourced from theconsumer or customer 11 when a transaction is requested by the customer11. If, however, the ANI and the BTN do not match, then the processormodule 54 generates a code 120 (see operation 66) to indicate that thecaller and the owner of the line number are not the same person (e.g.subscriber inputs a BTN and calls from a different ANI) and the relevantmodified code is then returned to the vendor 12. If the ANI and the BTNdo match, the processor module 54 interrogates the threshold database 20(see operation 68) to ascertain whether or not the line number hasreached its threshold (e.g., a predefined client threshold parametersuch as an account threshold indicating a maximum dollar amount that maybe charged to the account). If the line number has reached itsthreshold, the processor module 54 then generates a code 60, as shown atoperation 70, which is then communicated to the vendor 12 to indicatethat the line number should not be granted service. In other words, thesubscriber account cannot be billed for the goods or services requestedby the customer 11 from the vendor 12.

If the threshold for the particular subscriber line 17 has not beenreached, the system 10 may then interrogate its OFFNET database (seeoperation 71) to check if the industry standard NPA/NXX and operatingcompany number (OCN) of the subscriber line 17 is present in the OFFNETdatabase 22. The OFFNET database 22 includes NPA/NXX and OCNcombinations of operating companies with which the proprietor or user ofthe system 10 does not have billing and collection agreements to billinto the telephone company's or Telco's bill page associated with thesubscriber line 17. Accordingly, the proprietor or user of the system 10is unable to include a charge in the account associated with thesubscriber line 17 on behalf of the vendor 12 for the transactioncarried out with the vendor 12 via the subscriber line 17.

If the line number is in the OFFNET database 22, then the processormodule 54 generates codes 130 to 133 (see operation 72) and communicatesthese codes to the vendor 12. The codes 130 to 133 indicate that theNPA/NXX and OCN for the particular line number 17 are not billable and,accordingly, charges for goods and/or services requested by a customer11 via the subscriber line 17 cannot be included in a monthly account orthe like by the system 10. As shown in Table 2 below, the codes 130 to133 provide an indication to the vendor 12 why the subscriber line 17 isnot billable or deliverable. If the subscriber line number is notincluded in the OFFNET database 22, a check is conducted to see whetheror not the subscriber line number is included in the ONNET database 24.This check is however optional in the embodiment depicted in thedrawings, but in certain embodiments, may be mandatory if the system 10does not include the OFFNET database 22.

Thereafter, as shown in operation 78, the processor module 54 checks tosee if the line number 17 is found in a known CLEC table in the CLECdatabase 26. CLEC numbers are those line numbers that are known to haveported to a CLEC and, accordingly, the proprietor of the system 10 isthus unable to route these line numbers to the correct billing entities.If the line number is found in the CLEC database 26, then the processormodule 54 generates a code 140 (see operation 76), which is communicatedto the vendor 12. The code140 indicates that the line number is notbillable for the CLEC and the system 10 can thus not charge thetransaction to the subscriber account associated with the subscriberline 17.

If the line number is not found in the CLEC database 26, then the system10 may check to see if the subscriber of the line number has requested a4250 billing block as shown at operation 78. In particular, theprocessor module 54 interrogates the 42 BLOCK database 28 and, if thenumber is located in the database 28, which indicates that monthlyrecurring charges (4250 charges) are prevented from being billed to thatline number, the processor module 54 generates a code 150 (see operation80) which is communicated to the vendor 12 to indicate that billing tothe particular subscriber line 17 has been blocked.

If, however, the subscriber line 17 has not been blocked, the system 10may then check at operation 82 if the line number is located in theblock and cancel database 30 and, if so, the processor module 54generates codes 160 and 161 which are then communicated to the vendor 12as shown at operation 84. The block and cancel database 30 includesrequests from owners of subscriber lines, agencies, businesses, or thelike that a service be canceled or blocked from further billing.Thereafter, the system 10 may interrogate the unbilled and/or unpaidbills database 32, as shown at operation 86, to check if there is ahistory of any unpaid bills and/or unbillable bills associated with thesubscriber line 17. Unbillable bills relate to those subscriber linenumbers where previous attempts have been made to bill charges to thesubscriber account associated with the subscriber line number 17, andwhich have been returned as unbillable. If the processor module 54locates the subscriber line number in the unbillable and/or unpaid billsdatabase 32 then, as shown at operation 88, a code 170 is generated andcommunicated to the vendor 12 to indicate that the subscriber linenumber was previously found to be unbillable and is still considered tobe unbillable.

The processing described in the abovementioned operations may conduct apreliminary investigation into the subscriber line number or ANI toprovide an initial indication of whether or not the ANI corresponds witha billable subscriber line. Once the initial investigation has beenconducted in certain embodiments, the system 10 then uses the ANI toobtain reference subscriber line data in the form of LIDB codes from oneor more industry standard databases, e.g. the LIDB host or database 52.Examples of the LIDB codes used in the system 10 are shown in Table 3below.

As shown at operation 90, if the ANI is not found in the LIDB database52, then the system 10 cannot provide any validation data to the vendor12 on this subscriber line and an appropriate code is then communicatedto the vendor as shown at block 92.

Once the LIDS database or host 52 has been interrogated, it returnsindustry standard LIDB codes and line number portability (LNP) data tothe system 10 as shown in operation 94. The LIDB codes may then bemapped or translated by the processor module 54 into modified validationcodes (see Table 3 which provide relevant validation information to thevendor 12. As can be seen from Table 3, the same modified validationcode can be generated from a plurality of different LIDB codes. Once theLIDB information codes have been returned to the processor module 54,the LIDB codes, including an OCN and RAO response codes, are fed intothe validity check module 36 as shown at operation 96.

As mentioned above, the LIDB host 52 may also provide LNP data to thesystem 10. The LNP data is used to identify subscriber line numbers thathave ported to a CLEC. If a subscriber line has been ported to a CLEC,the billing ONNET status of the CLEC may be verified in the CLECdatabase 26. The LNP identifies the facilities based CLECs which areCLECs that have been assigned all the line numbers for an NPA/NXX in aspecific geographic territory. This type of CLEC may be in control ofthe cable, dial tone and billing envelope for that number. In oneexemplary embodiment, the LNP cannot be used to identify CLEC sellers,which have resold the subscriber line under their brand, but still leasethe cable and tone from an incumbent local exchange carrier (ILEC).Accordingly, a third-party billing facility, e.g. a proprietor or userof the system 10, may be unable to process transaction data onto a billpage of the CLEC reseller bill page. In order to identify resellerCLECs, the system 10 may compare RAO and OCN information, returned fromthe LIDB host 52, to data in the ONNET database 24. The OCN is the localTelco that owns the subscriber line number and the RAO is the office ofthe Telco that is responsible from a billing standpoint for thesubscriber line number.

If the validity check module 36 determines that the response codes areinvalid, the system 10 generates modified codes 180 to 999 (seeoperation 98 and Table 2) which are communicated to the requestor orvendor to indicate that the mapping of the LIDB codes to the modifiedcodes concluded that the line is an unbillable subscriber line.

If the validity check module 36 confirms the validity of the LIDB codesand, in the event of the line number being a billable line number, theprocessor module 54 then may check the RAO database 38 to ascertainwhether or not the RAO is billable, as shown at operation 100. If theRAO is not billable, then the processor module 54 generates andcommunicates a return code 143 (see operation 102) to indicate to thevendor 12 that the line number belongs to a CLEC which is not billableby the system 10.

In a similar fashion, at operation 104 the processor module 54 checks tosee if the OCN returned from the LIDB host 52 corresponds with a knownCLEC or if the OCN corresponds with an OFFNET OCN and is therefore alsounbillable by the system 10. If the line number corresponds to an OCNthat is not billable, a return code 142 is generated by the processormodule 54 and communicated to the vendor (see operation 106).

If the subscriber line number has passed the RAO and OCN checks and,accordingly, it appears that the number is billable, the processormodule 54 may then check to see if a new NPA/NXX and OCN combination forthis line number is guidable to the correct local Telco for billing (seeoperation 108). If the line number is not guidable, then the system 10generates a code 141 at operation 110 which is communicated to thevendor to indicate that, even though the line number is billable, theproprietor of the system 10 is unable to guide the billing informationto the new Telco for billing. Accordingly, the telephone number is infact non-billable insofar as the system 10 is concerned and a declinestatus is therefore communicated to the vendor 12.

The abovementioned operations are carried out to ascertain whether ornot the subscriber line can be billed for the goods and/or servicesrequested. However, to enhance the accuracy or reliability of the system10, further checks or verification may be conducted as described below.

In the event that the subscriber line number has passed or complied withthe abovementioned checks, and has thus not yet been rejected, thesystem 10 may perform address verification procedures at operation 112.In particular, when the ANI is communicated to the API 14, location datais also provided which has been fed in by the user, e.g. via a computerterminal, orally over a telephone, or the like. The system 10 theninterrogates an address verification database 44 to compare the addressor location data (e.g. a ZIP code) supplied by the customer 11 with areference address data as shown at operation 112. If, however, theaddress supplied by the customer 11 does not match with the address inthe verification database 44 or, the addresses are not within apredefined range or area, the processor module 54, as shown at operation114, generates codes 10 to 39 which are then communicated to the vendor12 to indicate the level of likelihood that the caller (ANI) and theaccount owner are the same person.

During the address verification operation 112, the system 10 mayinterrogate a customer account record exchange (CARE) database 46 (whichcan be an on-site database which is regularly updated), to provideenhanced reliability. In particular, in one exemplary embodiment, theCARE database 46 or information site is one or more industry standardoff-site databases which allow consumers to select or change their longdistance service provider. Local Telcos forward specific customerinformation to the LEC associated with the subscriber. In one exemplaryembodiment, the information communicated includes a new telephonenumber, a billing address, an installation date, a person ororganization responsible for the account, or the like.

As shown at operation 116, the system 10 may interrogate the CAREdatabase or information site and CARE data is then loaded into CLEC andnew line databases to perform certain fraud and/or billing checks. TheCARE information investigation may occur after a successful validationevent. In one embodiment, once the system 10 has validated thesubscriber line 17, the subscriber line number data is sent to a CAREdatabase provider hosting the CARE database 46 to obtain the BNA(Billing Name and Address) and age of the account. In one exemplaryembodiment, the information is returned within 48 hours and thenprocessed. CARE records that are returned without BNA and NO ACCOUNTcodes may be inserted into the CLEC database 26 for future reference.Accordingly, if the BTN is presented again at a later date, it will failthe CLEC check operation 74 (see FIG. 2).

The ANI watch database 48, which may include historical and adjustedinformation, may be used by the system 10 to determine if the accounthas previously been adjusted (see operation 116). In one exemplaryembodiment, this operation includes ascertaining previous requests bythe subscriber for credit, obtaining data on any written off amounts forcharges that were billed to a bill page, or the like.

If adjustments have previously been made to the account associated withthe subscriber line 17, the processor module 54 generates codes 1 to 5(see operation 118) to indicate to the vendor 12 that the adjustmentshave previously been made. If no adjustments have been made, theprocessor module 54 checks to see whether or not the subscriber linenumber has a business line indicator as shown at operation 120. If thebusiness line indicator is active, the system 10 generates a code 70(see operation 122), which is communicated to the vendor 12 to advisethat the line is a business line. Thereafter, as shown in operation 124,the processor module 54 may check to see if the subscriber line numberhas been in service for less than about 90 days and, if so, a returncode 80 (see operation 126) is generated to advise the vendor 12 who maythen selectively decide whether or not to conclude the transaction. Adatabase of new numbers may be updated with the new number.

Thereafter, the system 10 may interrogate the ANI watch database 48 (seeoperation 128) to ascertain whether or not the area code of the linenumber has been changed or is scheduled to change. In one embodiment,this interrogation is for billing purposes only and is not used todecide upon the validity of the request. In this operation, the vendor12 requesting the validation updates the billing file with the new areacode number, and the processor module 54 generates a code 110 (seeoperation 130) to advise the vendor 12 of the scheduled change to thearea code.

Once the line number has passed all the aforementioned checks, thesystem 10 may conclude that the subscriber line 17 is in fact a billablesubscriber line based on the data obtained using ANI techniques and,accordingly, the transaction may be charged directly to the account ofthe subscriber. Accordingly, the system 10 then generates a code 000(see operation 134) which is communicated to the vendor 12. The code 000may define an approved status following both a billable line numberinquiry as well as several fraud checks which are carried out by thefraud control module 132 (see FIG. 1). If the subscriber line number ofthe subscriber line 17 has passed the abovementioned checks and a returncode 000 is generated, the procedure shown in FIG. 4 is carried outwhereafter the process terminates at operation 136. Thus, operation 136may define the end of the process during which the various checks havebeen conducted on the subscriber line 17 to assess whether or not it isa billable subscriber line that charges may be billed to. Operation 138defines, in one embodiment, the last operation to which the processjumps when, at any point during the abovementioned process, the linenumber is found not to be billable (or a creditworthiness decision isrequested) and the inquiry is accordingly terminated and the relevantcode is communicated to the vendor 12.

In one exemplary embodiment, the abovementioned operations are executedin real-time. However, information sources that do not allow checks onthe line number in real time may be carried out subsequently on thesubscriber line number. In one embodiment, once the real-time evaluationis carried out and the return code 000 is communicated to the vendor 12,and should the vendor 12 decide to proceed with the transaction,transaction data is then returned to the system 10 by the vendor 12 fora pre-billing validation check or actual billing. During the actualbilling, the system 10 may access an account folder of the subscriberline at the Telco and insert the charges due to the vendor 12 for itsgoods or services. As shown at operation 140, subscriber line numbersmay be sent to the CARE database 46 to determine if the BNA is availableat the local Telco. If the folder is not available, the local Telcosends the BNA and codes as to why the number is unavailable. If the BNAis found in the CARE database 46, the processor module 54 may then checkto see whether or not the account was created within the last 90 days asshown at operation 142. If the account was not created within the last90 days, then the business indicator is checked as shown at operation144 and the process ends as previously shown at operation 146. If,however, the number was found in the CARE database 46, the account wascreated within the last 90 days, or has an active business indicator,then the system 10 may generate the appropriate codes, which arecommunicated to vendor 12, and the process terminates as shown atoperation 148.

The above process has been described in terms of modified codes set outin Table 2 but, it is to be appreciated, that any other defined set ofcorresponding codes may be provided so long as the codes are mappedonto, or generated in response to, any one or more of the industrystandard LIDB codes.

A summary of the codes generated by one exemplary embodiment of thesystem 10 during execution of the validation process is provided inTable 1 below.

TABLE 1 Modified codes generated during the BTN Validation Process. CodeGenerated and ref to flow charts Description of code Return Code 121Indicates inability to proceed with validation; returned to requestorSee operation 64 Checks if ANI captured and BTN provided match (notrequired in all scenarios) Return Code 120 Indicates caller and # (linenumber) owner are not the same person; returned to requestor Seeoperation 68 A defined Threshold limits the number of attempts on that #within a certain timeframe Return Code 60 Indicates # may not be grantedservice; returned to requestor. See operation 71 Checks the NPA/NXX andOCN to those in the OFFNET. OFFNET = NPA/NXX and OCN combinations whereproprietor of the system 10 does not have a Billing and Collectionsagreement to bill into the Telco's' bill page. Return Code 130-133Indicates that NPA/NXX & OCN for that Number are not billable; returnedto requestor See operation 74 Checks the line number to see if found inknown CLEC table. These are numbers that are known to have ported to aCLEC. Proprietor is unable to route these # to the correct billingentities. Return code 140 Indicates # not billable for CLEC; returned torequestor. See operation 78 Checks line # to see if owner has requesteda 4250 Billing block. This block prevents monthly recurring (4250)charges from being billed to that line #. Return Code 150 Indicates thatbilling to a particular subscriber line has been blocked; returned torequestor. See operation 82 Checks line number for inclusion in theBlock and Cancel database. This database includes requests from line #owners, agencies, businesses etc that have requested that service becancelled and or blocked from further billing. Return Code 160-161Indicates number found in Block and Cancel and is not billable; returnedto requestor. See operation 86 Checks line # for unbillable history.Unbillables are #s where tried to bill charges previously and have beenreturned as unbillable. Return Code 170 Indicates # has unbilled beforeand is still considered unbillable; returned to requestor. See operation90 If # not found in Unbillable, then routed to LIDB for info. ITEMDescription See operation 94 Identifies info returned from LIDB re. thatline #; Response Code = status about that # as a call termination point.OCN = Operating Company # = the local Telco that owns that #. RAO =Regional Accounting Office = the office of the Telco that is responsiblefrom a $ flow standpoint for that #. See operation 96 Checks thevalidity of the LIDB code returned for the number as a Billable #. Thisis where the mapping of the LIDB codes to the proprietor validationcodes happens. Return Code 180- Indicates the mappings of the LIDB codesto the proprietor Val reply 999 codes. Each of these indicate anon-billable #; returned to requestor. See operation 100 Checks if RAOreturned is an RAO that is not billable. Return Code 143 Indicates thatthe # belongs to a CLEC and is unbillable; returned to requestor. Seeoperation 104 Checks if OCN returned from LIDB is a known CLEC or OFFNETOCN and therefore unbillable. Return code 142 Indicates that the new OCNis not billable; returned to requestor. See operation 108 Checks to seeif new NPA/NXX & OCN combination for # is guidable to the correct localTelco for billing. Return code 141 Indicates that even though the # isbillable, the system is unable to guide to the new Telco for billing;unguidable = unbillable; # returned to requestor. The operations toindicate if # is billable have been completed. The next operationsprovide additional information about the # for the requestor e.g. todecide if and how much credit to extend for services. They also provideadditional billing information. ITEM Description See operation 112Provides address verification (if required). Matches # to address todetermine likelihood of person dialing to the person that owns theaccount at local Telco. Return Code 10- Indicates the level likelihoodthat the caller (ANI) and acct owner are 39 the same. Returned torequestor. See operation 116 Checks to see if # has had adjustmentactivity previously. This includes request for credit, written off forcharges that billed to a bill page. Requestor makes credit decisionbased on #s history of credits, adjustments, write offs. Return Code 1-5Indicates the type and source of adjustment to charges to that #.Returned to requestor. See operation 120 Checks to see if the # has abusiness line indicator. Requestor decides if would like to extendservice or not. Return Code 70 Indicates that the # is identified as abusiness. See operation 124 Checks to see if the # has been in serviceless than 90 days. Requestor makes a decision about how much service tooffer # without much payment history. Return Code 80 Indicates that the# has been in service less than 90 days. See operation 128 Checks if theArea Code of the # has been scheduled to change. This is for billinginformation purposes only. Requestor updates billing filed with newnumber. Return Code 110 Indicates Area Code has been scheduled tochange. New number is appended to end of record. See operation 134 Ifthe number passes all the previous checks, then 000 code is returned torequestor. The Validation is complete for this request. See operation138 End of validation for numbers that did not pass or were found inother checks. END OF REAL TIME VALIDATION EVENT Information sources thatdo not allow checks on the # in Real-time (r-t), happen on # that wasreturned as 000 after the r-t validation event has completed. The #s areloaded into the appropriate databases. This information will be providedonce the # is returned for billing. ITEM Description Operations 140,142, 144 Indicates path for those #s returned with a 000 code. Seeoperation 140 #s are sent to CARE source to determine if BNA (billingName and Address) available at local Telco. Telco sends BNA and codes asto why unavailable. CLEC #s that are returned with codes that indicatethe # has moved to a CLEC from the local Telco are loaded into the CLECtable. See operation 142 #s are sent to the CARE source to determine ifthe account has been crested within the last 90 days. The response codesindicate this condition. New within 90 #s that are returned with codesthat indicate this condition are loaded into the NEW table. Seeoperation 144 #s are sent to a Business source. This source identifieswhich numbers belong to businesses. Biz table Numbers that are indicatedas being line #s that belong to businesses are loaded in this table.

Table 2 (see below) provides the various actions, which are executed inresponse to a modified validity code. The table provides an exemplarydescription and explanation of each code. Return codes 001 to 179 relateto failure codes, which are generated by the system 10 prior toinvestigation of the LIDB host 52. Return codes 180 to 451 are generatedduring the LIDB code checks. In the event of the subscriber line 17failing the checks carried out on it, the system 10 provides optionaluse of a credit card and, accordingly, Table 2 sets out codes which thesystem 10 generates in response to executing a standard credit cardenquiry for a particular transaction. If the system 10, which may bedefined by a server and associated databases, is down, codes 994 to 999are generated and communicated to the vendor.

TABLE 2 Validation & BNA Reply Codes Code Action DESCRIPTION EXPLANATIONBILLABLE CODES 000 Approved Billable; was not found Passed all billingand fraud control during fraud control checks checks FRAUD CONTROL CODES(performed after billable check) ANI WATCH (adjustments to bill) 001Verify Billable; found in ANI Passed all billable checks; but ANIWATCH - CLIENT source had been adjusted previously at all vendor's,Client's or Telco's request for your Client # 002 Verify Billable; ANIWATCH - Passed all billable checks; but ANI CLIENT source Client hadbeen adjusted previously at Client's request for your Client # 003Verify Billable; ANI WATCH - Passed all billable checks; but ANI CLIENTsource Telco or had been adjusted previously at Vendor vendor's orTelco's request for your Client # 004 Verify Billable; found in ANIPassed all billable checks; ANI had WATCH - GLOBAL been adjustedpreviously at vendor's, Client's or Telco's request for all Client ids005 Verify Billable; found in ANI Passed all billable checks; ANI hadWATCH - PRODUCT been adjusted previously at vendor's, Client's orTelco's request for same product type ZIP VERIFICATION 010 VerifyBillable; Unable to match Passed all billable checks; unable to ZIPinvalid find this Zip code for this NPA/NXX - 011 Verify Billable; ZIPdoes not match Passed all billable checks; Zip code does not match thisNPA/NXX 012 Verify Billable; ZIP matches to Passed all billable checks;Zip code same Metropolitan area matches to same Metropolitan area as NPANXX. ADDRESS VERIFICATION 020 Verify Billable; BNA match not Passed allbillable checks; no BNA found match found for ANI 021 Verify Billable;Unable to verify Passed all billable checks; unable to BNA invalidverify BNA to ANI info sent 022 Verify Billable; with zip-Match, Passedall billable checks; BNA Zip plus4-Match, locale-Match code + 4 & locale(street address) matches info sent for ANI, Name does not match 023Verify Billable; with zip-Match, Passed all billable checks; BNA Zipplus4-Match, NoMatch- code + 4 matches info sent for ANI locale butlocale (street address) does not match 024 Verify Billable; zip-Match,Passed all billable checks; BNA Zip NoMatch-plus4, locale- code & locale(street address) Match matches info sent for ANI but + 4 does not match025 Verify Billable; zip-Match, Passed all billable checks; BNA ZipNoMatch-plus4, NoMatch- code matches info sent for ANI but locale locale(street address) & + 4 does not match 026 Verify Billable; NoMatch-zip,Passed all billable checks; BNA + 4 plus4-Match, locale-Match and local(street address) matches info sent for ANI Zip does not match 027 VerifyBillable; NoMatch-zip, Passed all billable checks; BNA + 4 plus4-Match,NoMatch- and locale (street address) matches locale info sent for ANIbut Zip does not match 028 Verify Billable; NoMatch-zip, Passed allbillable checks; BNA NoMatch-plus4, locale- locale (street address)matches info Match sent for ANI but ZIP and + 4 does not match 029Verify Billable; NoMatch-zip, Passed all billable checks; BNA doesNoMatch-plus4, NoMatch- not match zip, + 4 or locale (street localeaddress) sent for ANI 030 Good Address & Zip Match 031 Verify AddressMatch, Zip No Match 032 Verify Address Match, Zip Service Unavailable033 Verify Address No Match, Zip Match 034 Verify Address No Match, ZipNo Match 035 Verify Address No Match, Zip Service Unavailable 036 VerifyAddress Service Unavailable, Zip Match 037 Verify Address ServiceUnavailable, Zip No Match 038 Verify Address Service Unavailable, ZipService Unavailable AREA CODE CHANGE INDICATOR 110 Update Indicatesthere has been an Code is sent in addition to the area code change forthis validation response codes. New NPA/NXX phone number is appended torecord. Provided to update the account with the correct BTN.MISCELLANEOUS 120 Verify BTN and ANI do not match For use where BTN andANI are passed and do not match. 121 Verify BTN or ANI are missing Foruse where BTN and ANI is from record missing from record UNBILLABLECODES OFFNET 130 Unbillable NPA/NXX found in Area code/exchange OFFNET -GLOBAL (NPA/NXX) combination resides in OFFNET DB. OFFNET is a territorywhere the LEC (Local Exchange Carrier) is unable to provide 3rd partypresentation in to its envelope. 131 Unbillable NPA/NXX found in Areacode/exchange OFFNET - CLIENT (NPA/NXX) combination SPECIFIC resides inOFFNET DB specific for this Client id. 132 Unbillable NPA/NXX found inArea code/exchange OFFNET - PRODUCT (NPA/NXX) combination resides inOFFNET DB specific for this product type. 133 Unbillable NPA/NXX NOTVALID Area code/exchange is not a valid area code exchange CLEC (CLECsare unable to provide 3rd party bill presentation in their envelopes.)140 Unbillable Line number (NPA/NXX- BTN has been ported to a CLEC XXX)in CLEC Territory (competitive local exchange carrier). 141 UnbillableNPA/NXX not ON NET BTN has been ported to a CLEC (competitive localexchange carrier) and is not billable. 142 Unbillable Line number OCN inCLEC Operating Company number for OCN table this BTN was found on CLECOCN table. The number is not billable. 143 Unbillable Line number RAO inCLEC Regional Accounting Office RAO table number for this BTN was foundon CLEC RAO table. This BTN is not billable. 42 BLOCK (4250s Only) 150Unbillable Line Number has a block for Consumer has requested a block4250 records for all MRCs (monthly recurring charges) from being billedto this phone number. BLOCK & CANCEL 160 Unbillable GLOBAL - Line numberhas Consumer requested block to stop been blocked to stop all allcharges from being billed to this charges. number. 161 UnbillableCLIENT - Line number has Consumer requested a block to a block to stopall charges stop charges from being billed or from this Client id. tocancel service for this phone number from this Client id. UNBILLS 170Unbillable Line number is Unbillable. Line number has been returned fromthe Local Telephone companies within the last 6 months as unable to bebilled. LIDB FAILURE 180 Unbillable Line number failed LIDB Line Numberhas been returned check - GENERAL from LIDB as unbillable. 181Unbillable Vacant NPA NXX No working line #s in NPA NXX 182 UnbillableNo Incoming Calls Line # cannot accept incoming calls 183 UnbillableDenied ANI Auto decline of all attempts from this ANI 184 UnbillableCalling Card block Auto decline of Calling Card number 185 UnbillableCollect Call Block Auto decline of Collect calls to this number 186Unbillable Third Party Call Block Auto decline all Third Party billedcalls to this number 187 Unbillable Credit Card Block Auto decline ofcharges billed to Credit Card 188 Unbillable Group Number Block Autodecline of attempts from this group. 189 Unbillable Audiotext BockNumber does not allow audiotext calls. 190 Unbillable Excessive CallingCard PIN Threshold for calling card hits attempts has been exceeded. 191Unbillable Line Number Block Auto decline of all charges to this number200 Unbillable Excessive Use - BTN BTN has exceeded threshold 201Unbillable Excessive Use DN DN has exceeded threshold 202 UnbillableExcessive Use - ANI ANI has exceeded threshold 203 Unbillable ExcessiveUSE - Calling Calling Card Pin has exceeded Card Pin threshold 220Unbillable Feature Group A Local telephone switch is Feature Group A 221Unbillable PBX line Line # is a PBX line 222 Unbillable WATS line Line #is a WATS line 223 Unbillable Hotel/Motel Auto Quote w/ Hotel/Motel AutoQuote w/tax tax 224 Unbillable Hotel/Motel Auto quote w/o Hotel/MotelAuto quote w/o tax tax 225 Unbillable Dormitory line Line # belongs to adorm 226 Unbillable Hospital line Line number belongs to a hospital 227Unbillable Centrex line Line number belongs to CENTREX 228 UnbillableAlternate Service Provider Line # belongs to an alternate serviceprovider 229 Unbillable POTS line (collect or third Line # is plain oldtelephone service party calls) lines for business or residential 230Unbillable Pager # Line number belongs to pager 231 UnbillablePCS/Mobile/Cellular # Line number belongs to a wireless provider 240Unbillable Line was disconnected w/o Line # was disconnected w/o areferral referral number 241 Unbillable Line Number changing Line is notconnected yet. 242 Unbillable not used 243 Unbillable DISCO w/o referralLine number has been removed from service w/o referral 244 UnbillableTemp DISCO Line number has been removed from service temporarily 245Unbillable DISCO with referral Line number has been disconnectedw/referral or Operator takes calls 246 Unbillable Temp DISCO w/referralLine number has been removed from service temporarily w/referral 250Unbillable POTS line rating on rate plan POTS line is on a rate plan forbusiness or residential message rate 1 or 2 or flat rate 300 UnbillablePublic - Incompatible Public phone with incompatible interface interface301 Unbillable LEC Public Standard PreP LEC Public phone standardinterface; OT prepay overtime 302 Unbillable LEC Public Alternate LECPublic phone alternate interface; functions controlled by set 303Unbillable LEC Public Standard PP OT LEC Public phone standardinterface; postpay overtime 304 Unbillable IC Public IC Public Phone -Alternate Interface 305 Unbillable IC Public Standard IC Public Phone -Standard Interface 306 Unbillable LEC Public Special - PP OT LEC PublicPhone - Special billing post paid OT 307 Unbillable LEC Public Special -PreP LEC Public Phone - Special Billing; OT Pre pay OT 308 UnbillableLEC Semi Public LEC Semi Public Phone 309 Unbillable LEC Semi PublicPhone (no LEC Semi Public Phone does not collect or 3rd Party calls)allow collect or 3rd party calls to this number 310 Unbillable LECPrepaid Card LEC Prepaid Card Telecommunications station 311 UnbillableIPP (fka COCOT) Standard Payphone Standard interface 312 Unbillable IPP(fka COCOT) Alternate Payphone - Alternate interface 313 UnbillableCoinless (non IPP fka Coinless Pay phone COCOT) 314 Unbillable Coinless(IPP fka COCOT) Coinless payphone 315 Unbillable Prison (non IPP fkaPrison payphone COCOT) 316 Unbillable Prison (IPP fka COCOT) PrisonPayphone 450 Unbillable BNS: Voice Quote - without Charge quotes withouttax tax 451 Unbillable BNS: Voice Quote - with tax Charge quotes withtax CREDIT CARD RESPONSE CODES 000 Approved Credit card approved 501Decline/ User authentication Failed Error 502 Decline/ Invalid tenderYour merchant bank account does Error not support the following creditcard type that was submitted 503 Decline/ Invalid transaction typeTransaction type is not appropriate Error for this transaction. Forexample, you cannot credit an authorization- only transaction. 504Decline/ Invalid amount Error 505 Decline/ Invalid merchant informationProcessor does not recognize your Error merchant account information.Contact your bank account acquirer to resolve this problem. 512 Decline/Declined Please check the credit card number Error and transactioninformation to make sure they were entered correctly. If this does notresolve the problem, have the customer call the credit card issuer toresolve. 513 Decline/ Referral Transaction was declined but could Errorbe approved with a verbal authorization from the bank that issued thecard. Submit a manual Voice Authorization transaction and enter theverbal auth code 519 Decline/ Original transaction ID not Thetransaction ID you entered Error found for this transaction is notvalid. 520 Decline/ Cannot find the customer Error reference number 522Decline/ Invalid ABA number Error 523 Decline/ Invalid account numberPlease check credit card number Error and resubmit. 530 Decline/ AccountLookup information Account provided found in Error Mismatch system,however, unique key provided does not match unique key in system. 531Decline/ Account does not exist Account provided not found in Errorsystem 542 Decline/ Invalid expiration date Please check and re-submitError 525 Decline/ Transaction type not mapped Error to this host 526Decline/ Invalid vendor account Error 527 Decline/ Insufficient partnerError permissions 528 Decline/ Insufficient user permissions Error 550Decline/ Insufficient funds available Error 551 Decline/ Invalidtransaction returned Error from host 552 Decline/ Processor notavailable Error 553 Decline/ Credit error Please make sure you have notError already credited this transaction, or that this transaction ID isfor a creditable transaction. (For example, you cannot credit anauthorization.) 554 Decline/ Void error Please make sure the transactionError ID entered has not already been voided. If not, then look at theTransaction Detail screen for this transaction to see if it has settled.(The Batch field will be set to a number greater than zero if thetransaction has been settled). If the transaction has already settled,your only recourse is a reversal (credit a payment or submit a paymentfor a credit). 555 Decline/ Capture error Only authorizationtransactions Error can be captured 556 Decline/ Failed AVS check Addressand Zip code do not Error match 557 Decline/ Cannot exceed sales cap ForACH transactions only Error 558 Decline/ CVV2 Mismatch Error 800Unbillable LNP Only Look-Up, number LNP Only Look-Up, number was wasfound found in the LNP GTT database as ported. 801 Unbillable LNP OnlyLook-Up, number LNP Only Look-Up, number was was not found not found inthe T.NP GTT database, not ported. 802 Unbillable LNP Only Look-Up, theLNP Only Look-Up, the NPNXX NPA/NXX is not a portable is not a portablerange. range SYSTEM DOWN 994 Resubmit Message Format Error Messagereceived in invalid or unrecognized format. 995 Resubmit Time outSession timed out. 996 Resubmit Connection Failure Unable to connect.997 Resubmit Subsystem Failure Subsystem, such as LIDB, Credit Card,etc, not available. 998 Resubmit Network Failure Network Not Available999 Resubmit System Down System Unavailable Note: The result of an AVScheck does not mean that the transaction is declined. This informationmay be advice only. The system may compare the AVS data with billinginformation for the buyer and pass the results of the comparison to themerchant.

As mentioned above, the system 10 may translate the LIDB codes intomodified verification codes as shown in Table 2. These modified validitycodes are then mapped or translated. Table 3 below provides a list ofthe modified validity codes which are generated following the mappingcarried out by the processor module 54 to translate LIDB codes to themodified verification codes set out in Table 1.

TABLE 3 LIDB/LNP SOURCE TRANSLATIONS FOR ISP: Resp. Resp. Type Code LIDBrtfc In In ACTION ADMIN? Description type Code Out APP 000 ApprovedCalling card has an Unrestricted PIN. G1 000 APP 001 Approved Callingcard has a Restricted PIN. The g1 000 switch must verify that the DNImatches the first 10 digits of the calling card before placing the call.APP 004 Approved Collect call - No verification is required. G1 000 APP005 Approved Third-party call - No verification is G1 000 required. APP006 Approved There is a system error. S 999 APP 008 ApprovedCommunications Link Tests “Good.” S 999 APP 010 Approved Commercialcredit card is approved and the G1 000 zip code matches, if the zip codewas sent. APP 011 Approved Y Bill-to number has an Admin. Override to G1000 automatically approve the transaction. (Admin. Reply) APP 012Approved Originating number (ANI) has an Admin. G1 000 Override toautomatically approve the transaction. (Admin. Reply) APP 013 ApprovedDialed number (DNI) has an Admin G1 000 Override to automaticallyapprove the transaction. (Admin. Reply) APP 014 Approved Group numberhas an Admin. Override to G1 000 automatically approve the transaction.(Admin. Reply) APP 015 Approved Commercial credit card is approved butthe CC 500 zip code check is unavailable. APP 016 Approved Commercialcredit card is approved but the CC 501 zip code check is unavailable.Retry later. APP 017 Approved Commercial credit card is approved but theCC 502 zip code check is not supported. APP 018 Approved Commercialcredit card is approved and the CC 503 address matches but the zip codedoes not match. APP 019 Approved Commercial credit card is approved andthe CC 504 address and the zip code match. APP 020 Success LNP OnlyLook-Up, number was found in LNP 800 the LNP GTT database as ported. APP021 Success LNP Only Look-Up, number was not found LNP 801 in the LNPGTT database, not ported. CON 050 Verify Collect call number has noblock. Verify o1 000 acceptance of the charge. CON 051 VerifyThird-party call number has no block. 01 000 Verify acceptance of thecharge. CON 053 Denied Unable to authorize, Automatic Code S 999 Gappingis in effect at the LIDB. Every third query is dropped by the LIDB. CON054 Denied Y Excessive Use - The bill-to number exceeded G3 000 the highlimit threshold in the Admin. fraud control system. (Admin. Reply) CON055 Denied Y Excessive Bad PIN Attempts - The threshold 02 000 for badPIN attempts for the calling card was exceeded in the Admin. fraudcontrol system. (Admin. Reply) This is the same as reply code 309. CON060 Conditional Y Low Limit Warning - The bill-to number G3 000 exceededthe low limit threshold in the Admin. fraud control system. (Admin.Reply) CON 061 Conditional Y Low Limit Warning - The dialed number G3000 exceeded the low limit threshold in the Admin. fraud control system.(Admin. Reply) CON 062 Denied Y Excessive Use Dialed - The dialed numberG3 000 exceeded the high limit threshold in the Admin. fraud controlsystem. (Admin Reply) CON 063 Conditional Y No Host Still Billable -There is no LIDB G2 180 check available, but the Customer has a billingagreement with this LEC. (Admin. Reply) CON 064 Approved Y Commercialcredit card is approved but the CC 505 zip code and the address do notmatch. CON 065 Conditional Y Low Limit Warning - The ANI exceeded the G3000 low limit threshold in the Admin. fraud control system. (Admin.Reply) CON 066 Denied Y Excessive Use ANI - The ANI exceeded the G3 000high threshold in the Admin. fraud control system. (Admin. Reply) CON070 Approved Calling card has no service denial in the G1 000 CardService Denial Indicator field. Calling card calls may be billed to thiscard number. CON 071 Approved Calling card has no service denial in thePin G1 000 Service Denial Indicator field. Calling card calls may bebilled to this card number. CON 080 Verify Collect calls - Acceptintralata, Reject 01 000 interlata collect calls. Recommend verifyacceptance of the charge. CON 081 Verify Third-party calls - Acceptintralata, reject 01 000 interlata third-party calls. Recommend verifyacceptance of the charge. CON 082 Verify Collect calls - Acceptintralata, verify 01 000 interlata collect calls. Recommend verifyacceptance of the charge. CON 083 Verify Third-party calls - Verifyintralata, reject 01 000 interlata third-party calls. Recommend Verifyacceptance of the charge. CON 084 Verify Collect call - Verifyacceptance of the charge 01 000 by an Operator. CON 085 VerifyThird-party call - Verify acceptance 01 000 of the charge by anOperator. CON 086 Verify Collect call - Accept intralata charge, verify01 000 interlata charge with Operator. CON 087 Verify Third-partycalls - Verify intralata charge 01 000 with operator, reject interlatacharge with Operator. CON 088 Verify Collect Calls: POTS Line G5 000(Business/Residential) CON 089 Verify Third-Party Calls: POTS Line G5000 (Business/Residential) CON 090 Verify BNS: Centrex Line, Collectcalls - Some G4 000 LECs allow billing to this type of line, others donot. Verify Acceptance. CON 091 Verify BNS: POTS Line - Residential -Message rate 1 G9 000 CON 092 Verify BNS: POTS Line - Residential -Message rate 2 G9 000 CON 093 Verify BNS: POTS Line - Business - flatrate G9 000 CON 094 Verify BNS: POTs Line - Business - message rate 1 G9000 CON 095 Verify BNS: POTS Line - Business - message rate 2 G9 000 CON096 Verify BNS: POTS Line - Residential - flat rate G9 000 DENY 100Denied Message Format Error Message S 994 DENY 100 Denied Message FormatError - Date format S 994 DENY 100 Denied Message Format Error - HeaderMessage S 994 Error DENY 100 Denied Message Format Error - Merchant IDError S 994 DENY 100 Denied Message Format Error - No End of Header S994 Indicator DENY 100 Denied Message Format Error - Header Data S 994Indicator, did not contain data in each field of the message That wasrepresented by the message text map field DENY 100 Denied Message FormatError - PIN not numeric S 994 DENY 100 Denied Message Format Error -Terminating Error S 994 commercial credit card oni DENY 100 DeniedMessage Format Error - Terminating S 994 Number not numeric DENY 100Denied Message Format Error - Originating Number S 994 not Numeric DENY100 Denied Message Format Error - Charge Number not S 994 Numeric DENY100 Denied Message Format Error - No End Header S 994 Indicator DENY 101Denied Message Format Error Invalid S 994 Customer/Terminal ID NumberDENY 102 Denied Message Format Error Invalid Message S 994 Type DENY 103Denied Message Format Error Invalid Transaction S 994 Type DENY 104Denied Message Format Error Invalid Sequence S 994 Number DENY 105Denied Message Format Error Invalid Data S 994 Indicator DENY 105 DeniedMessage Format Error- Header Data S 994 Indicator DENY 107 Denied BadPIN format. PINs must be equal to or S 994 higher than 2000. DENY 200Denied Calling card blocked, missing customer S 994 record - There is norecord of that calling card number in the database. DENY 201 Denied BNS,missing customer record - There is no S 994 record of that line numberin the database. DENY 202 Denied Missing BNG - There is no record ofthat S 994 NPANXX in the database. DENY 203 Denied Non-billable NXX -DPC table failure. The G2 180 NPANXX does not have routing or allowbilling, e.g. cellular. (LIDB or Admin. Reply) DENY 204 Denied Callingcard blocked, screened data - A O2 000 screening mechanism is in placeat the LIDB that does not allow charges to this calling card. DENY 205Denied Protocol converter problem - There is a S 999 problem with theSS7 protocol converter. DENY 206 Denied BNS & No Calling Card Calls - NoHost, o2 180 Nonparticipating Group. This NPANXX exists but there is noLIDB host. (LIDB or Admin. Reply) DENY 207 Denied LIDB Access Deniedbecause no queries S 999 should be sent to this LIDB destination. Admin.Reply) DENY 208 Denied Calling card blocked, Screened Data on PIN O2 000(Pin Service Denial Indicator) - A screening mechanism is in place atthe LIDB that does not allow charges to this PIN. DENY 209 DeniedExternal SS7 Problem - There is a format S 999 problem in the SS7network DENY 210 Denied Calling card blocked, screened data - A O2 000screening mechanism is in place at the LIDB that does not allow chargesto this calling card. DENY 211 Denied Calling card is blocked because ithas O2 000 a bad PIN or the PIN does not match database information.DENY 211 Denied Unexpected Data Value, Calling card blocked, O2 000 BadPIN - This means a bad PIN was used or there is no PIN on file. DENY 212Denied Calling card blocked, PIN Excessive Use at G3 000 LIDB Owner. -The PIN exceeded the high threshold in the LIDB fraud control systemDENY 213 Denied Vacant BNG - There are no working lines in G2 181 theNPANXX. DENY 214 Denied No Collect calls - Collect calls are not O2 000allowed to this line number. DENY 215 Denied No Third-party calls -Third-party calls are O2 000 not allowed to this line number DENY 216Denied BNS: LEC Public - Standard Interface G10 303 (functionscontrolled by the network) - Postpay Overtime DENY 217 Denied BNS:Coinless (non IPP fka COCOT) G10 313 DENY 218 Denied BNS: semi-publicphone - No Collect or G10 309 Third-party calls are allowed to this linenumber. DENY 219 Denied Spare - This LIDB response is not in use at AV180 this time. DENY 220 Denied Time-out, No response from Host - A S 180response was not received from the host database within 4 seconds for aTelco query or 12 seconds for a Bank card query. (LIDB or Admin. Reply)DENY 221 Denied BNS Data unavailable, Error Message, No S 180 Host - Nocollect or third-party calls should be allowed to this line number. DENY222 Denied Calling card Data unavailable, Error S 180 Message, No Host -No calling card calls should be allowed to this line number. DENY 223Denied BNS & Calling card, screened response O2 000 LIDB - A screeningmechanism is in place at the LIDB that does not allow charges to thisaccount number. DENY 224 Denied LIDB Misroute - The query was routed toS 999 the wrong LIDB. DENY 225 Denied Reject, Reroute - The LIDB couldnot read S 994 the format of the query. DENY 226 Denied UnexpectedComponent - The LIDB cannot S 994 interpret the format of the query.DENY 227 Denied UDTS, SS7 Network problem - There is an S 999 SS7network problem. DENY 228 Denied BNS: Personal Communication Service G8231 (PCS) DENY 229 Denied BNS: Mobile G8 231 DENY 230 Denied NotBillable - The Customer does not have a G2 180 billing arrangement withthe LEC for this NPANXX (OCN On-Net Screening). DENY 231 Denied BNS: LECPrepaid Telecommunications G10 310 Card Station DENY 232 Denied FeatureGroup A (FGA) G4 000 DENY 233 Denied BNS: LEC Public - AlternateInterface G10 302 (functions controlled by set) DENY 234 Denied BNS: LECPublic - Special Billing - Postpay G10 306 Overtime (functionscontrolled by the network) DENY 235 Denied BNS: LEC Public - SpecialBilling - Prepay G10 307 Overtime (functions controlled by the network)DENY 236 Denied BNS: Public - Incompatible Network G10 300 Interface(interface other than standard or alternate) DENY 237 Denied BNS: ICPublic - Alternate Interface G10 304 DENY 238 Denied BNS: IPP (fkaCOCOT) - Standard Interface 311 DENY 239 Denied BNS: Pager G8 230 DENY241 Denied General, Reject - The LIDB could not read S 994 the format ofthe query. DENY 242 Denied Invoke, Reject - The LIDB could not read theS 994 format of the query. DENY 243 Denied Return Result, Reject - TheLIDB could not S 994 read the format of the query. DENY 244 DeniedReturn Error, Reject - The LIDB could not S 994 read the format of thequery. DENY 245 Denied Transaction Portion, Reject - The LIDB S 994could not read the format of the query. DENY 246 Denied BNS: VacantNumber - There is no line G2 180 number assigned. DENY 247 Denied BNS:Disconnected without referral - The G6 240 line number was disconnectedwith no referral to a new line number. DENY 248 Denied BNS: Changed tonon-published number - o5 000 The line number was changed to a non-published number. DENY 250 Denied No Collect Calls, Screened Data - A 02000 screening mechanism is in place at the LIDB that does not allowcharges to this line number. DENY 251 Denied No Third-party calls,Screened Data - A 02 000 screening mechanism is in place at the LIDBthat does not allow charges to this line number. DENY 252 Denied BNS:Screened Data - A screening G7 191 mechanism is in place at the LIDBthat does not allow charges to this line number. DENY 253 Denied BNS:Screened Data - A screening G7 191 mechanism is in place at the LIDBthat does not allow charges to this line number. DENY 254 Denied BNS &No Calling Card, Unavailable 02 411 network resource - This line or cardnumber is not in the database. DENY 255 Denied BNS: Screened Data - Ascreening G7 191 mechanism is in place at the LIDB that does not allowcharges to this line number. DENY 256 Denied BNS: Being changed - Theline number is G6 241 being changed; it may not yet be connected. DENY257 Denied BNS: May not yet be connected - The line G6 243 number may benew; it may not yet be connected. DENY 258 Denied BNS: Temporarilydisconnected - The line G6 244 number is temporarily disconnected. DENY259 Denied BNS: Disconnected, calls being taken by G6 245 operator - Theline number is temporarily disconnected, the operator is taking calls.DENY 260 Denied BNS: Temporarily removed from service - G6 244 The linenumber is temporally removed from service. DENY 261 Denied BNS: Not inservice for incoming calls - This G2 182 line number cannot acceptincoming calls. DENY 262 Denied BNS: Temporarily disconnected atcustomer G6 245 request without referral - The line number istemporarily disconnected at the request of the customer withoutreferral. DENY 263 Denied BNS: Temporarily disconnected at customer G6246 request with referral - The line number is temporarily disconnectedat the request of the customer with referral. DENY 264 Denied BNS:Changed with referral to new number - o5 000 The line number waschanged. A referral to another line number is in place. DENY 265 DeniedCalling card blocked, PIN Nonpayment - 02 000 The calling card isblocked because of nonpayment. DENY 266 Denied Calling card blocked,Service Restriction 02 000 on PIN - There is a service restriction onthis PIN. DENY 267 Denied Calling card blocked, no PINs assigned. 02 000There is no PIN assigned to this calling card/line number. DENY 268Denied Calling card blocked, service denial - There 02 000 is a servicerestriction on this calling card. DENY 269 Denied Calling Card - Thecalling card is a CIID 02 000 (proprietary card) for which there is nohost. DENY 270 Denied BNS: Unexpected Data Value - No Collect S 994 orThird-Party Calls are allowed. DENY 272 Denied LIDB/CCC ResponseTime-out - A response S 180 was not received from the host databasewithin 4 seconds for a Telco query and 12 seconds for a Bank query. DENY273 Denied No Collect Calls at Customer Request - The 02 000 end usercustomer requested the block for collect calls to this line number. DENY274 Denied BNS & No Calling Card Calls: Screened 02 000 data. DENY 275Denied BNS: Hotel/Motel Auto Quote - with tax G4 000 DENY 276 DeniedBNS: Dormitory Line G4 225 DENY 277 Denied BNS: Hotel/Motel Auto Quote -without tax G4 000 DENY 278 Denied BNS: PBX Line G4 221 DENY 279 DeniedBNS: Prison (IPP fka COCOT) G10 316 DENY 280 Denied BNS: WATS Line G4222 DENY 281 Denied No Third-party calls at Customer Request - 02 000The end user customer requested the block for third-party calls to thisline number. DENY 282 Denied BNS: LEC Public - Standard interface - G10301 Prepay Overtime DENY 283 Denied BNS: Coinless (IPP fka COCOT) G10314 DENY 284 Denied BNS: IC Public - Standard Interface G10 305 DENY 285Denied BNS: Voice Quote - without tax o6 450 DENY 286 Denied BNS: VoiceQuote - with tax o6 451 DENY 287 Denied BNS: IPP (fka COCOT) - AlternateInterface G10 312 DENY 288 Denied BNS: Hospital G4 226 DENY 289 DeniedBNS: Prison (non-IPP fka COCOT) G10 315 DENY 290 Denied BNS: LECSemi-Public G10 308 DENY 291 Denied BNS: Subsystem Congestion S 180 DENY292 Denied BNS: Subsystem Failure S 180 DENY 293 Denied BNS: Notranslation for address of such S 180 nature DENY 294 Denied BNS:Unequipped User S 999 DENY 295 Denied BNS: Network Failure S 180 DENY296 Denied BNS: Network congestion S 999 DENY 297 Denied BNS: Cellular(cellular is distinct from G8 231 mobile) DENY 298 Denied BNS andCalling Card - Although the G4 228 NPANXX belongs to SWBT the end-useraccount number is no longer is a SWBT customer. The line number nowbelongs to another local service provider. DENY 299 Failure LNP OnlyLook-Up, the NPANXX is not a LNP 000 portable range. DENY 301 Denied YDenied Originating Number (ANI) - The G2 183 ANI has an Admin. block toautomatically decline all attempts from this line number. (Admin. Reply)DENY 302 Denied Y Terminating Number (DNI) has an Admin. G2 182 block toautomatically decline all attempts to this line number. (Admin. Reply)DENY 303 Denied Y Calling card has an Admin. block to G2 000automatically decline all attempts to this line number. (Admin. Reply)DENY 304 Denied Y Collect Number has an Admin. block to G2 000automatically decline all attempts to this line number. (Admin. Reply)DENY 305 Denied Y Third Party Number has an Admin. block to G2 000automatically decline all attempts to this line number. (Admin. Reply)DENY 306 Denied Y Commercial credit card has an Admin. G2 000 block toautomatically decline all attempts to this line number. (Admin. Reply)DENY 307 Denied Y Group Number has an Admin. block to G2 000automatically decline all attempts from this group. (Admin. Reply) DENY308 Denied Y Global Negative Database Block - ‘There is G2 000 an Admin.block in the Global Negative Database to this line number for theAudiotext Industry. (Admin. Reply) DENY 309 Denied Y Excessive callingcard PIN hits - The G2 000 threshold for bad PIN attempts for a callingcard was exceeded in the Admin. fraud control system (Admin. Reply).This is the same as reply code 055. DENY 400 Denied Commercial creditcard, Invalid 506 Commercial credit card - This is not a validcommercial credit card account number. It failed the MOD 10 check. Alsoan invalid amount, invalid date or a format error may cause thisresponse. (Host or Admin. Reply) DENY 401 Denied Commercial credit card,Call issuer - The 507 authorization attempt triggered a flag in thefraud control system of the issuing bank, Banknet or VISAnet. DENY 402Denied Commercial credit card, Confiscate card - 508 No billing isallowed to this account number. If possible confiscate this card. DENY403 Denied Commercial credit card, Authorization 509 Declined - Nobilling is allowed to this account number. DENY 404 Denied Commercialcredit card, Unable to Validate 510 Account Number - There is problem inauthorizing this account number. DENY 405 Denied Commercial credit card,Card expired - No 511 billing is allowed to this account number becausethe card has expired. DENY 406 Denied Commercial credit card - InvalidMerchant 512 III. DENY 408 Denied Commercial credit card, Invalid cardand 513 Address (zip code) - Both the account number and the address orzip code are invalid. Do not allow billing to this account number. DENY409 Denied Commercial credit card, System Problem - 514 There is atechnical problem with the authorization system of the issuing bank,Banknet or VISAnet. DENY 420 Denied Commercial credit card, Overwithdrawal 515 limit - This account has exceeded the withdrawalthreshold in the authorization system of the issuing bank DENY 421Denied Commercial credit card, Over credit limit - 516 This account hasexceeded the credit threshold in the authorization system of the issuingbank DENY 422 Denied Commercial credit card, Lost card, 517 Confiscate -This account number was reported lost. No billing is allowed to thisaccount number. If possible confiscate this card. DENY 423 DeniedCommercial credit card, Stolen card, 518 Confiscate card - This card wasreported stolen. No billing is allowed to this account number. Ifpossible confiscate this card. DENY 424 Denied Commercial credit card,Invalid Pin - This 519 means a bad PIN was used. DENY 425 DeniedCommercial credit card, Allowable Number 520 of PIN Tries Exceeded - Thethreshold for bad PIN attempts for a calling card was exceeded in theauthorization system of the issuing bank, Banknet or VISAnet. DENY 426Denied Duplicate transaction. The Authorization 521 host considers thisa duplicate transaction.

In the embodiment of the invention depicted in the drawings, regardlessof the type of service provider or the type of validation request,clients or vendors may need a profile so that the process or methodcarried out by the system 10 knows how to treat the request. The clientor vendor profile may be set up in a database, which includes theindicators that are set for the type and tests for each request, whichwill be subsequently received from the vendor.

The first table shows the operations in the BTN test descriptionsprocess. In one exemplary embodiment, a set of core tests is run foreach client. Additionally, clients may have some configuration optionsto identify the tests that best fit their program.

PROCESS TESTs PURPOSE BILLABLE BTN TESTs VAL/Pre- Client profile Clientprofile for each id for BTN validation process test bill flags. VAL onlyANI = BTN Determines if originating number = BTN input by caller.VAL/Pre- Invalid # Ids Invalid NPAs & NXXs bill OFFNET VAL/Pre- GlobalOFFNET Ids (NPA)NXX & OCN combinations where there is not bill a B&Cagreement VAL/Pre- Product Ids (NPA)NXX & OCN combinations where thetraffic bill OFFNET type is riot approved to bill (Jul. 24, 2001: MRConly for NECA and Illuminet Only) VAL/Pre- Client OFFNET Ids (NPA)NXX &OCN combinations where there the bill Client id (7###) is not approvedto bill VAL/Pre- Special Calling Ids (NPA)NXX & OCN combinations ofspecial calling bill Card OFFNET card #s for non-calling card trafficthat are unable to be billed VAL/Pre- Plan OFFNET Ids (NPA)NXX & OCNcombinations where a Client bill Plan is not approved to bill VAL/Pre-ONNET Ids (NPA)NXX & OCN combinations where there are bill B&Cagreements VAL/Pre- CLEC Ids (NPA)NXX-xxxx's are not billable due toCLEC for bill all Clients. VAL/Pre- 4250 BLOCK Ids (NPA)NXX-xxxx's thathave a 4250 billing block bill (for MRC only) VAL/Pre- UNBILL Ids(NPA)NXX-xxxx's that have unbilled previously for bill all ClientsVAL/Pre- Block & Cancel - Ids (NPA)NXX-xxxx's that requested a Blockand/or bill GLOBAL Cancel; usually institutional VAL/Pre- Block &Cancel - Ids (NPA)NXX-xxxx's that requested a Block and/or bill ClientSpecific Cancel for a particular Client id VAL/1^(st) + Val Code CacheIds (NPA)NXX-xxxx & Return Code combinations for n Pre-bill previousrequest VAL/1^(st) LIDB Validity To determine the billable status of thereturn code from Pre-bill Test the LIDB dip VAL/1^(st) LIDB CLEC IdsRAOs that belong to CLECs Pre-bill RAO VAL/1^(st) LIDB CLEC Ids knownCLEC OCNs Pre-bill OCN VAL/1^(st) LIDB State To determine if thereturned LIDB code is a state Pre-bill Specific specific code and then aconversion to the billable OCN Conversion for the ONNET check VAL/1^(st)LIDB ONNET Ids billable (NPA)NXX & returned OCN combinations Pre-billALL VAL Trans Log Log of each validation request and response by ClientID BTN CREDIT SCORING VAL/Pre- AREA CODE Provides the new area code forthe line number while in bill Change permissive dialing period.indicator Val ZIP MATCH ZIP matches zip codes for (NPA) NXX (not inproduction as of 6/01) VAL/Pre- ANI WATCH - (NPA)NXX-xxxx's where therea refund/chargeback has bill CLIENT been issued previously for thisClient ID (SOURCE: all) VAL/Pre- ANI WATCH - (NPA)NXX-xxxx's where therea refund has been issued bill CLIENT previously for this Client ID(SOURCE: client) VAL/Pre- ANI WATCH - (NPA)NXX-xxxx's where there achargeback/bad debt bill CLIENT has been issued previously for thisClient ID (SOURCE: ebi/telco) VAL/Pre- ANI WATCH - (NPA)NXX-xxxx's wherethere a bill GLOBAL refund/chargeback/bad debt has been issuedpreviously (SOURCE: all) from CLIENT, ebi or telco VAL/Pre- ANI WATCH -(NPA)NXX-xxxx's where there a bill PRODUCT refund/chargeback/bad debthas been issued previously (SOURCE: all) for the same product VALAddress Not Available Verification Example TESTs VAL/Pre- Threshold byDetermines whether the BTN has met a Client specific bill Clientthreshold VAL/Pre- LEC PROV To determine if LEC owns Acct bill feedVAL/Pre- Credit Check Credit header files check from Credit source billVAL/Pre- New within 90 Determines if BTN is less than 90 days old;affects bill days credit score

On/Offnet Family Tables (Billing Coverage)

The OFFNET table family contains OCN & NPA_NXX combinations wherebilling is not approved. If found, the BTN does not continue on thevalidation path.

The ONNET table determines if an NPA_NXX & OCN combination can be foundamong the billable combinations. In this case a match allows the BTN tomove further on the validation path. A no match will return a failure.

The CLEC table consists of CLECs that the proprietor, or user of thesystem 10, does not have billing contracts with. This table is specificto the line number. Sources dictate the fields that will be present forthe record. A match here is considered a fail and does not continue.

The 4250 Block table consists of specific line numbers that cannot bebilled for 4250-01 record types. A match in this table stops thevalidation movement.

Bill Control Family Tables

The Unbills or unbillable table holds all the BTNs that have been sentto a subscribers' bill page but could not be placed on the bill page forvarious reasons. A match here halts the validation sequence for thesubject BTN.

Block and cancel tables identify BTNs that have requested a permanent ora Client specific block for billing. A match sends a failed response.

Validation Cache is a table that holds responses in order not to processduplicates (e.g. Submit pressed 10 times). A match here will return thecode stored from a previous request.

LIDS Family Tables

LIDB is a third party that supplies information to the phone line numberlevel. The goal is to test and store as many relevant fields as can berequested in a transaction.

The LIDB Validity Table translates the LIDB code into a billable ornon-billable response according to predefined business rules. A failhere will halt the validation for the request.

The State specific table is a conversion from a true OCN to a knownState Specific OCN that is billable. A match here will trigger theconversion, the BTN continues in the validation process.

The transaction log is the history of each transaction request andresponse that is processed through the validation system.

The TPM indicates that an NPA is in the permissive dialing period. Amatch here appends the record with the updated number for a recordupdate.

The ANI Watch has BTNs that have been given an adjustment for charges bythe Client, proprietor or user of the system 10 or the Telco. This is tohelp the client determine the credit score for the BTN.

Unlike the conventional use of the LIDB database that uses the LIDB datato obtain information on a destination/termination or recipient locationor subscriber unit, the system 10, in one exemplary embodiment, uses theindustry standard LIDB database to obtain relevant information on theinitiating subscriber line. The subscriber line reference data obtainedfrom the LIDB database is then processed to generate modified validitycodes, which provide a vendor with data to facilitate deciding whetheror not a transaction should be processed. The LIDB/LNP database may bequeried as if a collect call event is occurring and a call is thusmimicked. The processing of the transaction, in one exemplaryembodiment, involves communicating the relevant transaction data to afolder of the subscriber with a relevant Telco. The method of, andsystem 10 for, validating the billing account associated with thesubscriber line allows, for example, a subscriber line to be used tovalidate and conclude a transaction instead of using a conventionalpayment techniques such as a credit card, debit card, bank accountdetails or the like.

A current industry-wide problem is the lack of ability of a serviceprovider to identify when a line subscriber has switched his service toa CLEC since the service provider may not have an existing billingarrangement with such a CLEC and may also not have a source for the BNAto allow for a direct billing solution. LNP databases were originallyestablished for the purpose of directing call routing activities amongfacilities-based carriers and most telephone numbers ported to a CLEC donot involve a facility change (i.e. the CLEC is simply reselling theincumbent LEC's facilities). This means that, for billing decisionpurposes, LNP queries may provide an incorrect response.

In one embodiment of the present invention, the LNP queries have beenenhanced by analyzing and interpreting other field elements includedwithin the query response. Specifically, certain values or, in somecases, the absence of certain values, in the Operating Company Number(“OCN”) and/or the Regional Accounting Office (“RAO”) fields, allowsfurther accuracy in the validation response. While the definitions ofthe OCN and RAO field elements can be obtained from industry sources,their interpreted use in the validation process is unique to the presentinvention. Use of these additional data elements can improve thereliability of the validation event.

In addition, the present invention may include supplementing LNP resultswith CARE queries in LEC regions where LNP results are inadequate andCARE costs are not otherwise prohibitive based on the retail price ofthe underlying service. CARE may provide a reliable result onCLEC-ported numbers since its basic purpose is to provide subscriberaccount information (such as billing name and address). Once a number isported to a CLEC, the incumbent LEC no longer has subscriberresponsibility and will, therefore, return an “unavailable” response,even if the LEC's dial-tone facility is still being utilized. Thisnegative response is then used to generate a “deny” status on thesubscriber based on the current lack of CLEC billing support.

The exemplary embodiment of the present invention may supplement thevalidation process through the use of internal databases built frominformation gathered throughout the billing and collection process andprocess logic gleaned from previous billing experience.

It is important to appreciate that all of the operations in the methodexecuted by the system 10 need not be executed in real-time. In oneexemplary embodiment, after the approval code 000 has been generated bythe system 10 at operation 134, the system 10 terminates itspre-validation check routine as shown at operation 136. At this pointthe system 10 may merely provide pre-validation data or verificationdata to indicate to the vendor 12 whether or not the subscriber line isbillable. Thus the system 10 may, in a first interaction with the vendor12 provide pre-validation data, and in a second interaction processbilling information. During the processing of billing information thevalidation process may once again be executed. In certain embodiments,the first interaction may be in the form of a registration processduring which the validation procedure is carried out to register asubscriber line. The vendor may then conduct numerous transactions withsubscriber and subsequent validation checks on the subscriber line maythen only be carried out on a periodic basis.

After the validation code has been sent to the vendor 12, and thepre-validation procedure has been completed, the system 10 then carriesout the fraud checks on a non real-time basis (usually during the next48 to 72 hours) as shown in operations 140 to 144. The informationobtained during the fraud control check, if necessary, is used to updatethe various databases. In particular, after a BTN has been successfullyvalidated but before a billing event takes place, the CARE investigationoperations 140 to 144 may be executed. In the exemplary embodiment, thesystem 10 is arranged to interrogate off-site CARE databases and theresults of the enquiry are stored in the CARE database 46. Checks on thedata received from the CARE databases are then performed; whereafter oneor more of the other databases may be updated with the results. Forexample, the CARE database may be updated with new within 90 daysinformation, business indicator information, or the like. In theexemplary embodiment, CARE codes 2618 and 2619 indicate that the BNA isnot available and that the LEC no longer owns the account.

The updating of the databases following the CARE investigation may allowenhanced future checks by the system 10 in a subsequent pre-validationprocedure or subsequent registration validation event. The updatedinformation may be provided to the vendor 12. However, if the BTNinformation returned from the CARE database does not meet predefinedcriteria, the other databases of the system 10 may not be updated.

In the embodiment described above, information on the subscriber line 17is forwarded by the service provider or vendor 12 to the system 10 forvalidation. However, in other embodiments of the invention, the consumeror customer 11 may call the system 10 directly, as shown by line 150 inFIG. 5, and the ANI may then be obtained by the system 10 directly fromthe customer 11 and not indirectly from the vendor 12. Furthersubscriber line data, e.g. BTN, address of the customer 11 and so on,may then also be obtained directly from the customer 11. For example,the customer 11 may have appropriate software installed on his/her PCwhich allows the customer 11 to dial into the system 10 in an automatedfashion should he/she wish to charge any requested goods or services tohis/her subscriber account. The system 10 would then validate thesubscriber line number 17 using the method described above. The system10 then typically communicates a validation code (e.g. corresponding toapproval non-approval) to the vendor 12 as shown by line 152. The vendor12 would then conclude the transaction with the customer 11 if thesubscriber line has been validated.

The proprietor or user of the system 10 may function as a type ofclearing house. In particular, the proprietor or user of the system 10may be responsible or accountable for payment for the goods or servicesfor each transaction to the service provider or vendor 12 and, in turn,receive payment from the Telco 13. As mentioned above, the system 10 mayupdate the telephone bill or account of the subscriber in an automatedfashion (see line 154) and the account that the subscriber or customer11 receives (see FIG. 6 and line 156 in FIG. 5) includes the charges forthe goods and/or services provided by the vendor 12. The customer 11 maypay the Telco 13 (see line 155), the Telco 13 may pay the system 10 (seeline 156), and the system 10 may pay the vendor 12 (see line 160). It isimportant to appreciate that these payments need not take place at thesame time. In one exemplary embodiment, the payments between the Telcoand the system 10, and the system 10 and vendor 12, take placeperiodically in a batch fashion, causing the machine to perform any oneof the methodologies discussed above, may be executed.

FIG. 7 shows a diagrammatic representation of machine in the exemplaryform of a computer system 600 within which a set of instructions, forcausing the machine to perform any one of the methodologies discussedabove, may be executed.

The computer system 600 includes a processor 602, a main memory 604 anda static memory 606, which communicate with each other via a bus 608.The computer system 600 may further include a video display unit 610(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system 600 also includes an alpha-numeric input device 612(e.g., a keyboard), a cursor control device 614 (e.g., a mouse), a diskdrive unit 616, a signal generation device 618 (e.g., a speaker) and anetwork interface device 620.

The disk drive unit 616 includes a machine-readable medium 622 on whichis stored a set of instructions (software) 624 embodying any one, orall, of the methodologies or functions described herein. The software624 is also shown to reside, completely or at least partially, withinthe main memory 604 and/or within the processor 602. The software 624may further be transmitted or received via the network interface device620. For the purposes of this specification, the term “machine-readablemedium” shall be taken to include any medium that is capable of storing,encoding or carrying a sequence of instructions for execution by themachine and that cause the machine to perform any one of themethodologies of the present invention. The term “machine-readablemedium” shall accordingly be taken to included, but not be limited to,solid-state memories, optical and magnetic disks, and carrier wavesignals.

Thus, a method and system to validate data associated with a subscriberline of a telecommunication network have been described. Although thepresent invention has been described with reference to specificexemplary embodiments, it will be evident that various modifications andchanges may be made to these embodiments without departing from thebroader spirit and scope of the invention. Accordingly, thespecification and drawings are to be regarded in an illustrative ratherthan a restrictive sense.

What is claimed is:
 1. A method comprising: obtaining a telephone numberassociated with a subscriber account of a telecommunications network;obtaining first reference subscriber data associated with a subscriber,said first reference subscriber data being different from the telephonenumber; accessing a first database location using the telephone numberto determine second reference subscriber data; comparing the firstreference subscriber data and the second reference subscriber data; andverifying an identity of the subscriber if the first referencesubscriber data corresponds to the second reference subscriber data. 2.The method of claim 1, further comprising, prior to the verifying,accessing a second database location using the telephone number todetermine that the subscriber account associated with the telephonenumber is billable.
 3. The method of claim 1, further comprising:receiving a transaction amount to be charged to the subscriber account;and in response to the verifying of the identity of the subscriber,approving the transaction.
 4. The method of claim 1, wherein thetransaction is for a good or a service unrelated to use of a subscriberline associated with the subscriber account.
 5. The method of claim 4,wherein the transaction is for a good or a service, the good or theservice being selected from the group consisting of an online game,music and software.
 6. The method of claim 1, wherein the telephonenumber is obtained from a merchant of goods or services.
 7. The methodof claim 1, wherein the first reference subscriber data is obtained froma merchant of goods or services.
 8. The method of claim 1, wherein thefirst reference subscriber data is a ZIP code, PIN code, or password. 9.The method of claim 1, wherein the first database location is in a firstdatabase and the second database location is in a second database, thefirst database being distinct from the second database.
 10. The methodof claim 1, wherein the comparing of the first reference subscriber dataand the second reference subscriber data comprises determining whether amatch exists within a predefined range or geographic area.
 11. Themethod of claim 1, further comprising providing a verification statusnotification to a merchant device via a network upon verifying theidentity of the subscriber.
 12. The method of claim 2, whereindetermining that the subscriber account associated with the telephonenumber is billable comprises determining whether the subscriber accounthas reached a maximum monetary amount.
 13. The method of claim 2,wherein determining that the subscriber account associated with thetelephone number is billable comprises determining whether a billingblock has been imposed on the subscriber account.
 14. The method ofclaim 1, wherein the method is performed in real-time.
 15. The method ofclaim 1, further comprising: receiving a monetary amount from a merchantof a sales transaction between the merchant and the subscriber; andelectronically billing the monetary amount to the subscriber account.16. The method of claim 1, wherein accessing the first database locationand the second database location comprises requesting a search of atleast one database.
 17. The method of claim 1, wherein thetelecommunications network is a wireless telecommunications network andthe telephone number is a wireless number.
 18. A non-transitorymachine-readable medium for storing a set of instructions that, whenexecuted by a machine, cause the machine to: obtain a telephone numberassociated with a subscriber account of a telecommunications network;obtain first reference subscriber data associated with a subscriber,said first reference subscriber data being different from the telephonenumber; access a first database location using the telephone number todetermine second reference subscriber data; compare the first referencesubscriber data and the second reference subscriber data; and verify anidentity of the subscriber if the first reference subscriber datacorresponds to the second reference subscriber data.
 19. A systemcomprising: a network interface device to receive: a telephone numberassociated with a subscriber account of a telecommunications network,and first reference subscriber data associated with the subscriberaccount, the first reference subscriber data being different from thetelephone number; and a processor to execute instructions stored inmemory, the instructions comprising: accessing a first database locationusing the telephone number to determine second reference subscriberdata, and comparing the first reference subscriber data to the secondreference subscriber data to verify an identity of the subscriber basedon the comparison.
 20. The system of claim 19, wherein thetelecommunications network is a wireless telecommunications network andthe telephone number is a wireless number, and the transaction is for agood or a service unrelated to use of a subscriber wireless lineassociated with the subscriber account.